The present invention relates to a method of adapting client communications traffic for encapsulation within carrier Ethernet by providing an appropriate client/server adaptation mapping protocol for the traffic in a communications network and related aspects thereof.
In particular but not exclusively, the invention relates to a mapping protocol for a plurality of different types of client traffic into Ethernet traffic for transport over an Ethernet carrier network which removes the need for individual Ethertypes to identify the different types of client traffic.
Ethernet was originally devised as a connectionless packet based communications protocol for local area networks where each packet comprises an Ethernet frame. Here the term “packet” refers to a unit of data at any layer of the protocol stack, prior to or after transmission, whereas the term “frame” refers to a unit of data transferred across the network, defined at the datalink (network access) layer of the Open Systems Interconnection (OSI) protocol stack.
More recently, however, Ethernet standards are emerging that have extended the reach of the communications protocol to wider area networks such as the Provider Backbone Bridging (PBB) developed in the International Electrical and Electronic Engineering (IEEE) standards body as 802.1ah. This allows the transparent carriage of a client Ethernet layer network over a server Ethernet layer network. However, since the server Ethernet layer network is connectionless it cannot provide any strong resource assurances to the client Ethernet layer network.
To address this Provider Backbone Bridging—Traffic Engineered (PBB-TE) is also being developed by the IEEE as the 802.1Qay standard. The proposed 802.1Qay standard describes how an Ethernet hierarchy can be implemented to transparently carry conventional (connectionless) Ethernet client LANs over a connection-oriented packet-switched transport network infrastructure as a carrier service. However, where a PBB-TE carrier network is provided problems exist when other non-Ethernet traffic is to be transported over the PBB-TE network. This is not possible using the existing 802.1ah frame structure which is predicated on an Ethernet client.
PBB-TE is a connection-oriented Ethernet protocol which enables connectionless Ethernet to be carried as a client signal in the connection-oriented Ethernet layer using Media Access Control (MAC) in MAC encapsulation. Non-Ethernet client signals do not require MAC in MAC encapsulation. Moreover, it is desirable for non-Ethernet clients to be carried directly over a PBB-TE network using 802.1ad specified Ethernet equipment. This requires the client protocol to be identified using an Ethertype which acts as the protocol identifier. However, this is a far from ideal solution as many non-Ethernet clients do not have an Ethertype currently specified (and may never get such Ethertypes).
Whatever form of Ethernet to be used as a carrier technology, either in its connectionless or connection-oriented form, client traffic must be identified. The term client traffic refers herein to traffic originating in a network which consumes bandwidth available in another network for communications purposes. The network whose bandwidth is consumed by client traffic is referred to herein as a carrier network. A client traffic signal can comprise a communications signal corresponding to another communications protocol from the communications protocol used by the carrier network. The connection-oriented packet-switched and connectionless Ethernet standards require client data which is encapsulated within the payload of an Ethernet frame to be identified by means of a predetermined field value in the Ethernet frame header referred to by those of ordinary skill in the art as an “Ethertype”. Each different type of communications protocol requires an Ethertype identifier before, it can be transported using Ethernet. To obtain an Ethertype, an application is submitted to the IEEE Ethernet standards body which is a time-consuming process.
Accordingly, a problem exists in that client traffic cannot be encapsulated within carrier Ethernet unless an Ethertype already exists for that client traffic type. A possible solution would be to request new Ethertypes for all the possible types of client traffic (in addition to Ethernet) that one may wish to carry in advance. Another possible solution is to map the client Ethernet frames into other technologies instead of using an Ethernet-based server layer network. For example, in the Synchronous Digital Hierarchy/Synchronous Optical NETwork (SDH/SONET) and Optical Transport Network (OTN) communication protocols the standardised mechanism is to use Generic Framing Procedure (GFP) and on a Passive Optical Network PON a similar mechanism known as GPON Encapsulation Mode (GEM) is used. This does not, of course, resolve the problem of how to carry such clients over an Ethernet-based server layer network.
Accordingly, to overcome the problems associated with ‘client identification’ in a client/server layer network when the server layer is Ethernet (including PBB and PBB-TE variants) without requiring an Ethertype for each specific client case, one embodiment of the invention proposes a mapping scheme in which client traffic is first mapped to a GFP adaptation layer prior to being mapped to a carrier Ethernet frame. By mapping one frame of client traffic to one GFP frame it is possible that the GFP frame size exceeds that of a standard Ethernet carrier frame, in which case a larger size Ethernet frame may be provided. However, this may result in a bandwidth inefficient mapping scheme.
Conventionally, it is not possible for an Ethernet frame to carry more than one type of client traffic within its payload as no mechanism exists to identify the type of client traffic contained. However, as the adaptation layer is consistent for different types of client traffic according to the invention it is possible to map more than one GFP frame carrying the same or different client traffic types (for example, the same traffic but from different sources or different types of client traffic communications protocols (especially where these are from the same source) within an Ethernet frame of sufficient size, for example within a so-called Jumbo Ethernet frame
We thus now only require an Ethertype for GFP and not each of the clients that are carried. The problem of client identification has not disappeared however, but it is now resolved within GFP.